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CROSS REFERENCES TO RELATED APPLICATIONS 
The present application claims priority to and is a continuation in part of 
U.S. Serial No. 60/170,079 field 12/9/99, commonly owned, and hereby incorporated by 
reference. Additionally, the following commonly-owned co-pending apphcations, 
including this one, are being filed concurrently and the others are hereby incorporated by 
reference in their entirety for all purposes: 

1 . U.S. Patent Application Serial No. , (Attorney 

Docket Number 19838-000810); 

2. U.S. Patent AppUcation Serial No. , (Attorney 

Docket Number 19838-000820); 

3. U.S. Patent Application Serial No. , (Attorney 

Docket Number 19838-000830); and 

4. U.S. Patent Apphcation Serial No. , (Attorney 

Docket Number 19838-000840) 

BACKGROUND OF INVENTION 
The present invention relates generally to digital video processing 
techniques. More particularly, the invention provides a technique including a system for 
capturing audio and video information firom a first source and displaying such video and 
audio information at a second source, where the format of the first source and the format 
of the second soiirce are different firom each other. Merely by way of example, the 
present invention can be appHed to a wireless communication environment. It would be 
recognized, however, that the invention has a much broader range of applicability. For 
example, the invention can be applied to devices such as personal computers, personal 
digital assistants, cellular phones, lap top computers, note book computers, work stations, 
television sets, web appliances, all other devices which can communicate over a network 
and which are capable of outputting audio and/or video. 

Long distance wireless communication has evolved over many years of 
human development. At one time, people commimicated to each other over extended 
geographical locations by primitive wireless methods. Yelling or shouting often provided 



the only way to communicate from one person to another person in a wireless manner. 
Face to face yelling or shouting was often very effective. Such yelling, however, was 
often limited to the strength of the yelling person's voice, which could generally not carry 
greater than 300 feet or so. Additionally, environmental factors such as rain, wind, or 
snow limited the length of distance that could be communicated over effectively. 
Although effective for close distances, long distance wireless communication over larger 
geographical spans would often be ineffective. 

Other ways of communicating using a wireless medium followed. For 
example, drumbeats replaced, in part, yelling or shouting. Certain tribal people 
commimicated over great geographic distances to inform others of "danger" or the like 
used drumbeat signals. These signals were effective for some appUcations but still 
involved physical human means for implementing and carrying out the signals. 
Depending upon the strength of the person, drumbeats provided limited intensity. 
Additionally, drumbeats possessed poor "signal to noise" after a certain distance. 
Accordingly, drumbeats had to be replaced, at least in part. In some cultures, carrier 
pigeons carried messages between people over extended geographic areas. Small 
messages, which were written on scraps of paper, often attached to legs of carrier 
pigeons, which flew from one location to another location. In many urban areas, these 
carrier pigeons were quite effective in sending messages. Although somewhat effective, 
many limitations still existed. For example, only a limited amoxmt of information could 
be attached to the small legs of the carrier pigeon. Additionally, carrier pigeons often 
died, when diseased. Further, carrier pigeons required feed and had to be cleaned, since 
they were quite messy. Accordingly, carrier pigeons also had to be replaced. 

Many of these primitive techniques have been replaced by radio, cellular 
phones, television, and other modem day communication means. These communication 
means were often good for communicating a certain type of information. For example, 
radio transmits voice information, such as people, songs, and the Uke, which is broadcast 
to a plurality of users. Cellular phones also transmit voice information. Such phones 
provide user to user communication. An example of a modem day technology for 
cellular phones is a technology commonly called "CDMA" developed by Qualcomm of 
San Diego, CaUfomia. CDMA allows a user of a cellular phone to call anyone from 
anywhere in a mobile maimer in the United States. Television similar to radio also 
provided broadcast communication of video programs to a wide variety of users. 
Television would be broadcast using television towers or satellites and the like. 
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Despite the availability of these modem day techniques, numerous 
limitations still exist. All of these techniques often have different formats, which make 
information difficult to transfer from one device type to another device type. Such 
formats are also difficult to control especially for a combination of audio and video 
mformation. Further, each of these techniques is often single purpose, which also limits 
use of each of these techniques. Additionally, video broadcasting for personal content 
information could not be distributed, effectively, since many end user devices often used 
different formats and the like. Although there have been many advances, there are still 
nimierous limitations, as noted. 

From the above, it is seen that a technique for providing video information 
to people in an improved manner is highly desirable. 

SUMMARY OF THE INVENTION 
According to the present invention, techniques including a system for 
digital video processing are provided. In an exemplary embodiment, the present 
invention provides a system for personal broadcasting where the source audio/video and 
the displayed audio/video can be ui a different format. 

In a specific embodiment, the present invention provides a system for 
transferring real time video information from a source device to one of apluraUty of 
output devices. The system includes an image-capturing device for acquiring video 
information. The image capturing device comprises a processor, a graphics module 
coupled to the processor, a browsing device coupled to the processor, an image capturing 
franscoding device coupled to the processor, and an output device coupled to the 
processor for transferring the packetized stream of information through a wireless 
medium. The image capturing franscoding device adapted to convert the video 
information into a packetized sfream of information. The packetized sfream of 
information is in a first format. The system also has a network gateway coupled to the 
image-capturing device through the wireless medium. The network gateway coupled to a 
worldwide network of computers. The network gateway comprises a gateway 
transcoding device for converting the packetized stream of information in the gateway 
from the first format to a second format. The network gateway also comprises an output 
device for fransferring the packetized video information in the second format. The 
system has a display device coupled to the network gateway through the worldwide 
network of computers. The display device has a display and a franscoding device for 
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converting the packetized video information into video information for display. The 
display device also has a display for displaying the video information on the display 
device through a browsing device. 

In an alternative specific embodiment, the present invention provides a 
system for personal broadcasting from a mobile image capturing device to one or more 
mobile display devices and a cHent device throu^ a gateway server. The system has a 
personal broadcasting web site coupjed to a wide area network of computers and coupled 
to a wireless network. The system also has a transcoding module coupled to the personal 
broadcasting web site to covert an incoming audio/video signal from a first format into a 
second format for use in a wireless remote device. A look up table coupled to the 
personal broadcasting web site for selecting a processing module for converting the 
audio/video signal from the first format to the second format is also included. The 
processing module is one of a plurality of processing modules for converting an 
audio/video signal from one format mto another different and often incompatible format. 

According to yet another embodiment of the present' invention, a system 
for personal broadcasting to a mobile display device is described that includes a 
processor, and a personal broadcasting server coupled to the processor and coupled to a 
wide area network of computers. The personal broadcasting server includes an image 
retrieval portion configured to retrieve incoming video signals in a first format, a look up 
table coupled to the personal broadcasting web site for determining parameters for a 
second format for the incoming video signals, and a transcoding module coupled to the 
image retrieval portion and to the look up table, the franscoding module configured to 
convert the incoming video signal from the first format into the second format in response 
to the parameters. 

According to yet another embodiment of the present invention, a 
distributed system for broadcasting personal sfreaming data includes a video data source 
coupled to a network, the video data source configured to provide an output sfream of 
video data, the output sfream of video data having a first set of video parameters, a client 
device coupled to the network, the cUent device configured to receive an input sfream of 
video data, the input stream of video data having a second set of video parameters, and 
configured to output a device identifier, and a gateway server coupled to the video data 
source and to the client device across the network, the gateway server configured to 
receive the output stream of video data and to receive the device identifier, and in 
response to generate the input sfream of video data in response to the device identifier. 



4 



At least one parameter in the first set of video parameters is larger than a corresponding 
parameters of the second set of video parameters. 

Numerous benefits may be achieved by way of the present invention over 
conventional techniques, hi some embodiments, the present invention provides an easy to 
implement personal broadcasting system using conventional analog or digital video 
cameras and the like. The invention also provides a way for one mobile device to 
communicate audio/video with another mobile or wireless device, even if the devices are 
not generally compatible with each other. Li other aspects, the invention provides a novel 
broadcast server, which is coupled to a worldwide network of computers, including an 
internet or the Internet. Depending upon the embodiment, one or more of these benefits 
may exist. 

These and other benefits are described throughout the present specification 
and more particularly below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a simpUfied diagram of a broadcasting system according to an 
embodiment of the present invention; 

Fig. 1 A is a simplified diagram of an audio/video server according to an 
embodiment of the present invention; 

Fig. 2 is a simplified diagram of a personal broadcastuig gateway cluster 
according to an embodiment of the present invention; 

Figs. 2A to 2E are simpUfied diagrams of video uiformation stream flows 
according to embodiments of the present invention; 

Figs. 3 and 3A to 3D are simplified flow diagrams illustrating broadcasting 
methods according to embodiments of the present invention; 

Figs. 4 and 4A to 4B are simplified flow diagrams illustrating viewing 
methods according to embodiments of the present invention; 

Fig. 5 illustrates an embodiment of the present invention; 

Fig. 6 illustrates an embodiment of the present invention; and 

Figs. 7, 8, and 9 are simplified diagrams of an embodiment of a personal 
broadcasting system according to an embodiment of the present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 
Fig. 1 is a simplified diagram of a broadcasting system 100 according to an 
embodiment of the present invention. This diagram is merely an example, which should 
not xmdvily limit the scope of the claims herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and alternatives. In an exemplary 
embodiment, the present invention provides a personal broadcasting system for 
broadcasting personal video and audio. As shown, the broadcasting system includes a 
variety of elements such as a world wide network of computers 101, which can be an 
intemet, the Internet, or the like. The network can be coupled to an alternative wide area 
network, a local area network, an intranet, any combination thereof, and others. 

Central in the system is a personal broadcasting web site 103 or Web site, 
which is coupled to the network. Personal broadcasting web site includes many elements 
such as a personal broadcasting web server ("PBWS") coupled to a personal broadcasting 
gateway cluster, which will be described later. Personal broadcasting web server 
provides command and control information, as shown by the dotted lines, between the 
gateway cluster, a pluraUty of chent devices 123, and a plurality of personal broadcasting 
audio/video servers 125. Other devices can also exist in the network. Each of the 
plurality of audio/video servers provides audio/video data to be broadcast either to a 
group of viewers, a single user, the public, or any combination thereof. Each of the 
viewers is defined by each of the cUent devices 123, which are also coupled to the 
worldwide network. 

The personal broadcasting web site can be accessed by any of the servers. 
Each of the servers is a source of audio/video data. As merely an example, Fig. lA is a 
simplified diagram of an audio/video server according to an embodiment of the present 
invention. This diagram is merely an example that should not limit the scope of the 
claims herein. One of ordinary skill in the art would recognize many other variations, 
modifications, and variations. As shown, like reference numerals are used in this Fig. as 
some of the other Figs, for cross referencing purposes. The web site 103 is coupled to the 
Intemet 101. The web site includes a database 101, which stores profile information 135 
for each of the client devices. Profile information 137 is also stored for each of the 
personal broadcasting audio/video servers. Profile information is entered into the web 
site by any of the techniques described herein and others. Fvirther details of the profile 
information is provided below. The personal broadcasting web site transfers audio/video 
data from the website to the plurality of chent devices 123, e.g., 1 1, IX, 21, 2Y, Nl, NZ. 
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The client devices can include a personal computer, a work station, an internet appliance, 
and a mobile computing device. The mobile computing device is preferred. Here, the 
mobile computing device includes a browsing device which couples to the personal 
broadcasting audio/video servers. Details of the mobile computing device is provided in 

U.S. Serial No. (Attorney Docket No. 19838-000310), commonly 

assigned, and which is incorporated by reference for all purposes. 

Fig. 2 is a simplified [diagram of a personal broadcasting gateway cluster 
200 according to an embodiment of the present invention. This diagram is merely an 
example, which should not unduly limit the scope of the claims herein. One of ordinary 
skill in the art would recognize many other variations, modifications, and alternatives. As 
shown, the gateway cluster 200 includes a variety of elements such as a plurality of 
archive servers, which are each coupled to each other through common line 204, which is 
coupled via line 206 to the Internet 209. Archive servers are coupled to control 203 
server, which is also coupled to the Internet. Other elements include a database coupled 
to the network and a plurality of gateway servers 207, which are each coupled to the 
Internet. The gateway cluster interfaces with the personal broadcasting web server for 
control information. Audio/video data from any of the server devices are distributed to 
one client, a group of chents, or to the public, or any combination thereof. Further details 

of the gateway cluster are described in U.S. Serial No. (Attorney 

Docket No. 19838-000830), commonly assigned, and hereby incorporated by reference 
for all purposes. 

In a specific embodiment, each of the archive servers includes a processing 
unit coupled to a mass memory device. The mass memory device is capable of storing 
streaming video. Here, the mass memory device can be a variety of devices such as a 
tape device, a hard disk drive, a removable hard disk drive, floppy drive, optical drives, 
and many other drives. Each of these servers can be coupled to each other through a 
common bus 204 for scaling piarposes. Here, additional servers can be added without any 
detrimental influence in performance or the like. In a specific embodiment, each of the 
gateway devices is also coupled to a common interface such as the Internet. Accordingly, 
it is possible to add additional gateway servers without any detrimental influence in 
performance and the like. 

Figs. 2A to 2E are simplified diagrams of video information stream 
flows according to embodiments of the present invention. These diagrams are merely 
examples which should not limit the scope of the claims herein. One of ordinary skill in 
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the art would recognize many other variations, modifications, and alternatives. Figs. 2A 
to 2E are simplified diagrams of video information stream flows according to 
embodiments of the present invention. These diagrams are merely examples which 
should not limit the scope of the claims herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and altematives. As shown. Fig. 2A 
includes a video device drive 211, which generates video data. The video data is 
compressed into a first compressed packetized stream, which is transferred to the personal 
broadcasting web site 210 via the Internet or the like. Details of such technique is 

described in U.S. Serial No. (Attorney Docket No. 19838-0003100), 

commonly assigned and hereby incorporated by reference. For easy reading, video 
device driver is used herein as data acquisition block, which can be a part of the web site. 

As shown, the video device transfer compressed data through the Internet 
to a frame buffer 213. In the present embodiment, firame buffer 213 is used to buffer the 
stream of video data from data acquisition block, for processing by transcoder block 217. 
In this embodiment, the type of data and the rate at which firame buffer is updated are 
fixed by data acquisition block 211, under control of control block 215. In this 
embodiment, the data stored in frame buffer 213 may include pixels of video data having 
associated values (imcompressed); frames of video data that have been compressed with a 
quantized DCT operation; and the like. In one embodiment of the present invention, the 
video data may be stored in RGB component space, YUV component space, HSV 
component space, gray scale, and the like. 

In one embodhnent of the present invention, frame buffer 410 typically 
includes one or two buffers, each having a frame size of approximately 800 horizontal 
pixels by 600 vertical pixels (800x600). Each buffer typically has a bit-depth of at least 
24 bits in one embodiment. Frame buffer 410 is typically minimally embodied as a 3 
Megabyte DRAM, although larger sized memories may also be used. Alternatively, 
SRAM devices or embedded DRAM, or the like may also be used. In this embodiment, 
transcoder block 215 retrieves incoming data from frame buffer 213 fully decompresses 
or partially decompresses the data, reduces the bandwidth of the data, and forms a stream 
of output data in a desired format. Transcoder block 217 receives the bandwidth 
requirements and the desired output format from control block 215. Further detail 
regarding transcoder block 217 will be given below. 

In the present embodiment, stream caster block 219 is typically used to 
receive a stream of output video data from transcoder block 217 and to format the data for 
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transmission to network interface 221 . In this embodiment, network protocols used 
include TCP/IP protocols, although in other embodiments, other network protocols may 
also be used. In this embodiment, stream caster block 219 packetizes the output data 
stream, and determines IP addresses, payload lengths, and the like. Further, stream caster 
block 219 forwards the data segments into the appropriate TCP socket of network 
interface 221. 

In this example, netwprk interface 221 receives the segmented data from 
stream caster 219 and transmits the data to a network. The network, may be a computer 
network such as the Internet, a LAN, or the like. In the present embodiment, the network 
is TCP/IP based. In the present embodiment, network interface 221 is used to create, 
monitor, and close all the TCP/IP sockets and RTSP. In this embodiment, network 
interface also sends and receives data to and from a network via the TCP/IP sockets and 
sends incoming data to confrol block 215. In alternative embodiments, network interface 
may use other network protocols such as IPX, and other conventional and ftiture- 
developed network protocols. Further, network interface 221 may use other data 
streaming protocols such as RTP, and any other conventional and ftiture-developed 
streaming protocol. 

Fig. 2B illustrates a simplified block diagram according to an embodiment 
of the present invention. In particular, Fig. 2B illustrates ftmctional blocks available in a 
transcoder 240 according to one embodiment. Transcoder 240 includes a cropper block 
227, a sampler block 229, a frame rate block 230, a color depth block 231, a bit rate 
control block 233, an encoder block 235, and an encryptor block 237. As was illustrated 
in Fig. 2A, transcoder is coupled to a frame buffer, and outputs data to stream caster, in 
the present embodiment. 

In Fig. 2B, cropper block 227 retrieves frames of data from frame buffer. 
In this embodiment, cropper block exfracts a rectangular region of data from each frame 
retrieved from frame buffer. The extents of the rectangular region are specified in a 
"stream table" when receiving streaming video data. If no cropping is specified, cropper 
block 227 merely grabs the whole frame. Cropping is specified when there is a particular 
portion within a video frame that the requester wants to see. 

Also illusfrated in Fig. 2B is a sampler block 229 that receives input from 
cropper block 227. In this embodiment, sampler block receives a desired output spatial 
resolution from control block. In one embodiment of the present invention, sampler 
block, subsamples the image received from cropper block, to obtain the desired output 
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resolution. As an example, an incoming frame may have 640 horizontal pixels x 480 
vertical pixel resolution, however the desired output video image is 80 pixels x 60 pixels. 
In such an example, cropper block may simply take every eighth pixel of the incoming 
frame for the output frame. Other methods of subsampling are also contemplated, for 
example, cropper block may average eight pixels to obtain the value for the output pixel. 
Other methods, such as filtering, for subsampling are contemplated in alternative 
embodiments of the present invention. 

In another embodiment, sampler block 229, supersamples the image from 
cropper block, to obtain the desired output resolution. As an example, an incoming frame 
may have an 80 x 60 pixel resolution, however the desired output video image has a 640 x 
480 pixel resolution. An example of this may be a hand-held wireless video camera 
transmitting live video to a newsroom computer via the Internet. In such an example, 
cropper block may use any conventional method for upscaling the image. For example, 
cropper block may use pixel replication, with or without bi-ltnear, or bi-cubic filtering 
techniques, and the like. Other methods for upscaling the incoming frame are 
contemplated in alternative embodiments of the present invention. 

In the present example, frame rate block 230 receives the sampled frames 
of data from cropper block. Frame rate block 230 also receives an indication of a desired 
frame rate for output video from control block, typically in frames per second (Q)s). In 
the present embodiment, confrol block also knows the frame rate of the incoming video, 
also in ^s. This frame rate is also sent to frame rate block. 

In one embodiment, of the present invention, frame rate block compares 
the incoming frame rate to the desired output frame rate, and adjusts the number of 
frames accordingly. For example, frame rate block will drop frames of data to lower the 
number of frames per second, or will add frames of data to increase the number of frames 
per second. In the case where the output frame rate is lower than the input frame rate, 
frame rate block may use a counter to count to a specific number. When the number is 
reached, the current frame is dropped, or alternatively, the current frame is not dropped. 
For example, if the desired frame rate is 10 ^s and the incoming frame rate is 1 1 fps, 
every time a counter counts to 10, the next frame is simply dropped. As another example, 
if the desired output frame rate is 5 fps, and the incoming frame rate is 30 fps, every time 
the counter counts to 6, the next frame is not dropped, but is passed to the next fimctional 
block. 
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In another embodiment, frame rate block may be embodied as a first-in 
first-out frame (fifo) stack. In such an example, frames of input video are stored in a 
buffer location specified by a write pointer, and frames of output video are retrieved from 
a buffer location specified by a read pointer. In operation, every incoming video frame is 
written into the fifo stack, however, only when the frame is to be output is the write 
pointer incremented. In such a case, data read out of the fifo stack may be sequential. 
Still other methods for reducing the frame rate are contemplated in alternative 
embodiments of the present invention. 

in an alternative embodiment of the present invention, frame rate block 
adds frames to increase the frame rate. For example, if the incoming frame rate is 10 fps, 
and the desired frame rate is 20 ^s, frame rate block 530 will add frames to the video 
sfream every other frame. One technique for increasing the nimibers of frames involves 
interpolating the motion vectors of blocks in the frames. Many other methods for adding 
frames and increasing the frame rate are contemplated in alternative embodiments of the 
present invention, however are outside the scope of the present technical disclosure. 

In the example in the Fig., color depth reducer block 23 1 sequentially 
receives the frames of data from frame rate block. In one embodiment, color depth 
reducer block also receives an indication of the bit-depth for pixels in the incoming frame 
of data, and the desired bit-depth. In the present embodiment, in response to the bit 
depths, color depth reducer block 231 maps the number of bits from the input frame to the 
desired number of bits in the output frame. 

As an example, the incoming image may have a 30 bit bit-depth, for 
example three component color having 10 bits of hue data, 10 bits of saturation data, and 
10 bits of intensity data; the desired bit depth of the output frame may be 6 bit gray scale. 
In such an example, to reduce the color depth, color depth reducer block may take only 
the 6 most significant digits in the intensity data for the output frame. 

In another example, the incoming image may have a 24 bit bit-depth, for 
example, an RGB image having 24 bits of information (8:8:8), and the desired bit depth 
of the output frame may be 256 colors, or 8-bit color. In such an example, color depth 
reducer may re-map or dither, the values from the 24 bit color space into the 8 bit color 
space. Such dithering techniques are well known. In alternative embodiments, other 
types of techniques may be used to reduce the bit depth from an input video frame to 
obtain a desired output frame bit-depth. In alternative embodiments of the present 
invention, increasing the color bit-depth may also be performed, using known techniques 
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In the present embodiment, bitrate control block 233 receives the output 
from color depth reducer block. In the present embodiment, bit rate control block also 
receives a desired output bit rate from control block. For M-JPEG encoding, bit rate 
control block 233 is used to statistically compute a new quantization scale factor for the 
data so that the effective bit rate more closely matches the desired output bifrate. 

In the present embodiment, a quantization scale factor is frrst determined. 
The quantization scale factor is used to compress or expand a frame of data so that it 
more closely matches the desired output bit rate. In theory, in one embodiment the 
quantization scale factor is equivalent to a modulus (Mod) operator, or a most significant 
bits (MSBs) operator. In such cases, the differences between pixels that are close in value 
(e.g. 20 and 21), are ignored. As another example, values 20-23 maybe considered the 
same as 20. In this example, the quantization scale factor is determined by analyzing the 
number of bits per second are produced by a tO frame of data. The number of bits is 
divided by the frame time to obtain a calculated bit rate in this embodiment. This 
calculated bit rate is compared to a desired bit rate to obtain the quantization scale factor. 

The quantization scale factor is then applied to scale the next frame of 
data, a tl frame of data. Continuing the example above, the next frame of data may be 
scaled by 2, so that the bit rate of the next frame of data will be 10 kbps. In the present 
embodiment, bit rate scaling is performed by reducing the effective color depth by the 
quantization scale factor, to meet the desired bandwidth requirements. In this example, 
the color depth is halved, i.e. the bottom least significant bits (LSBs) are ignored. 

In one embodiment of the present invention, bit rate control block 
monitors each frame, and attempts to control the bit rate to match the desired output bit 
rate for virtually all frames. In some embodiments, the quantization scale factor is 
updated every frame time, and in other embodiments, the quantization scale factor may be 
updated every Xth frame time. Where X is selectable automatically or manually. 

In an alternative embodiment, a more simpHstic techniques is utilized. In 
such an embodiment, if the incoming bit rate is above the desired output bit rate, a 
predetermined quantization scale factor is applied to the next frame. Further, if the 
incoming bit rate is below the desired output bit rate, another predetermined quantization 
scale factor is apphed to the next frame. In such an embodiment, such predetermined 
quantization scaling factors may be selected ahead of time, based on empirical data, or the 
like. Still, in other embodiments of the present invention may provide for increasing the 
effective bit rate. Encoding block 235 next receives the bit-rate adjusted frames of data. 
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Encoding block may also receive a request for an encoding data format, specified for by 
control block. Encoding block is embodied as an MPEG encoder. Encoding block may 
include dedicated hardware encoders, such as those available firom Sigma Designs, and 
the like. 

In the present embodiment, for MPEG-1, MPEG-2, and MPEG-4 
encoding, it is contemplated that I-fi:ame data will be compressed. In another 
embodiment, P-fi:ames, and even B-^ames may also be compressed. For MPEG-4 
encoding, it is contemplated that both I-frame data and P-frame data be compressed for 
transmission purposes. Detail description of I, P, and B frames are outside the scope of 
this technical disclosure. In other embodiments of the present invention, alternative 
formats may specified, for example *.avi format video, *.mov format video, streaming 
video such as m the *.rm format from Real Networks, or *.asf format from Microsoft, or 
the like. Such formats may be in the public domain, or proprietary. Further, encoding 
block 560 may be embodied as specialized dedicated hardware, or as software routines on 
a digital signal processor (DSP), a microprocessor (Athlon, Pentiumlll), or the like. After 
encoding, the video data may be encrypted by encryptor block 237. 

The above embodiment was illustrated in the Fig. as having specified 
interconnections between blocks. However, in alternative embodiments of the present 
invention, the different blocks may be interconnect in different ways, and may be 
dynamically interconnected in different ways. As an example, an incoming frame may 
include 24-bits of 640x280 color image whereas the desired output image is an 8 bit 
80x60 gray scale image. In such an example, it is preferable to reduce the color depth 
information, before subsampling the image for sake of efficiency. In such a case, the data 
is passed to the color depth reducer 540 then to the sampler block. The interconnections 
between the blocks, and the data flow may be dynamic, and change according to specific 
need. 

An example of a personal broadcasting server according to the present 
invention can be provided by any one or a combination of the simpHfied diagrams of 
Figs. 2C to 2D. As shown, the server 250 receives video data from video device 251, 
which couples to driver device 252. The server 250 also receives audio data from sound 
device 268, which couples to sound card driver 267. Master control 261 communicates 
between video interface 253, audio interface 262, and network interface 260, as well as 
other blocks. Video data enters video input interface, which transfers the video into a 
series of blocks 254 including frame buffer 255, video processing 256, video compression 
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257, stream casting 258, and network interface 259. Additionally, audio transfers through 
the audio input interface, which transfers the audio through a sequence of blocks 266 
including audio compression 263, stream casting 264, and network interface 265. Each of 
these blocks carry out functionality common known in the art as well as described above 
and throughout the present specification. The personal broadcasting server generally 
receives video data in a first format and converts such video data into a second format for 
transmission over to a client device, , which is coupled to the network. Here, the video 
data in the first format cannot effectively be used by the client device. 

If implemented in hardware or partially in hardware, an efficient 
multiplexer or cross-bar mechanism can be used for embodiments of the present 
invention. If implemented in software, little if any additional hardware interconnections 
are typically required. Additionally, the above description in terms of specific hardware 
is merely for illustration. It would be recognized that the functionality of the hardware be 
combined or even separated with hardware elements and/or software. The functionality 
can also be made in the form of software, which can be predominantly software or a 
combination of hardware and software. One of ordinary skill in the art would recognize 
many variations, alternatives, and modifications. Details of a personal broadcasting 
process according to the present mvention are provided below. 

A personal broadcasting process according to an embodiment of the 
present invention is briefly described below: 

1 . Connect to personal broadcasting web server; 

2. Register user to broadcast audio/video; 

3. Set-up session for audio/video; 

4. Activate broadcast; 

5. Monitor broadcast; 

6. Correct and/or archive broadcast, as necessary; 

7. Terminate broadcast; and 

8. Perform any other steps. 

The above sequence of steps is merely an example. The steps can be 
performed on, for example, from a client device such as a personal computer or the like, 
which is coupled to the Internet. The steps provide an easy to use process for personally 
broadcasting audio/video information from a source to a client device. Preferably, the 
cHent device is mobile. The mobile client device includes the ones noted above as well as 



14 



others. Details of the present process are described in more detail below in reference to 
the Fig. 

Fig. 3 is a simplified flow diagram 300 illustrating a personal broadcasting 
method according to an embodiment of the present invention. This diagram is merely an 
example, which should not unduly limit the scope of the claims herein. One of ordinary 
skill in the art would recognize many other variations, modifications, and ahematives. As 
shown, the flow diagram includes a variety of steps, but begins with a registration 
process, step 301, which is followed by steps of setting up a session (step 303), activating 
the broadcast (step 305), monitoring the broadcast (step 307), and terminating the 
broadcast (step 309), among others, if desired. Here, a client device (a personal 
broadcasting audio/video server) connects to a personal broadcasting web server, which is 
coupled to a worldwide network of computers, such as an internet or the Internet. The 
web server can be similar to the one noted above, but can also be others. The client 
device can include a personal computer, a personal digital assistant, a pager, a personal 
computer, a notebook computer, a laptop computer, and a workstation, among others. 

Next, the potential broadcaster registers (step 301) with the web site. Fig. 
3 A is a simphfied flow diagram 311 illustrating a personal broadcasting registration 
method according to an embodiment of the present invention. This diagram is merely an 
example, which should not unduly limit the scope of the claims herein. One of ordinary 
skill in the art would recognize many other variations, modifications, and alternatives. 
Once the user is connected to the web site, the user (who is the potential broadcaster) fills 
(step 311) out a registration form on the web site. The registration form includes fields 
for a user name, password, profile information, and other information. The profile 
information can include a list of private viewers in various groups or a designation for 
public broadcasting. In some embodiments, it may also include demographics and other 
information, which may be used by marketers, advertisers, and other agents, in 
identifying product and other information, which may be of interest to the broadcaster. 
Profile information also includes details of the camera or other audio/video source device 
used by the broadcaster as well as the bandwidth available to the broadcaster, the 
processing unit, memory, and operating system of the broadcaster's server or computer. 
The registration form is entered firom the client, which sends the form to the server via the 
network. 

The web site script validates the form, step 313. If the form is valid, the 
method continues to the next step. Otherwise, the method returns via branch 3 16 to the 
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form again, which continues until a predetennined number of times or becomes valid. 
The web site issues and records (step 317) the user name and password. Additionally, the 
profile information is recorded (step 319) by the web site. Next, the personal 
broadcasting server software is downloaded (step 321) from the web site onto the 
broadcaster's device. The personal broadcasting server registers (step 323) with the web 
site, using the downloaded software. The method ends at step, 325. 

Optionally, the broadcaster's personal broadcast page is created and book 
marked, step 327. Here, the broadcaster can track the uniform resource locator (URL) of 
the broadcaster's personal web page. Once at this page, the broadcaster will often only 
need to cHck on a button on the web page in order to begin the broadcasting session. The 
broadcaster's personal broadcast page can be accessed by the broadcaster from anjwhere 
on the Internet and not just from the broadcaster's personal computer and camera. 
Accordingly, the broadcaster can remotely setup, start, or stop a broadcasting session 
simply by clocking on a start button on the personal web page. 

Once registration is completed and broadcasting software has been 
downloaded, the method sets up a broadcasting session. For example, Fig. 3B is a 
simplified flow diagram 330 illustrating a personal broadcasting setup session according 
to an embodiment of the present invention. This diagram is merely an example, which 
should not unduly limit the scope of the claims herein. One of ordinary skill in the art 
would recognize many other variations, modifications, and alternatives. The method 
begins by connecting a broadcaster's audio/video server onto the broadcasting web site. 
Next, the broadcaster logs (step 331) onto a designated web site, which is often the 
broadcaster's personal web page, such as the one noted above. Optionally, the 
broadcaster edits (step 335) the user profile, which was previously provided. 

Next, the broadcaster specifies procedural information about the broadcast, 
step 333. In a specific embodiment, the broadcaster enters information such as time for 
broadcast, keyword or words of description of broadcast content (e.g., sports, family, 
personal, product demonstration), limit of access (e.g., pubhc, private, group list), and 
excepted length of session, as well as other procedural information. This information is 
often entered as text information in fields on a graphical user interface. The text 
information including the procedural information is transferred from the broadcasting 
audio/video server to the web site of personal broadcasting server. 

The broadcasting server begins a countdown time, including a zero for 
immediate start, step 337. The countdown time often begins automatically, but can also 
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be initiated manually or semi-automatically. Once the designated start time has been 
reached, the broadcasting server is ready to accept stream requests from the client 
devices. Next, the web site from the personal broadcasting web server communicates 
with the broadcasting audio/video server to verify that it is in countdown mode. If the 
audio/video server is not in countdown mode, failure occurs, step 347. The broadcasting 
audio/video server outputs an error message, step 341, to the web site. The web site 
receives the error message and adds a failed session set entry into the broadcaster's log, 
step 343. Next, the method will exit, step 357, where the method can return back to one 
of the above steps or others. 

If the countdown has been verified, the setup method is success, step 345, 
and processing of setup information (step 349) occurs at the web server. Here, the web 
site receives and enters sfream information into a database, which is coupled to the server. 
In a specific embodiment, the web server may include advertisements or other 
information that may be attached to streaming video. Here, the web site script queries 
and then selects a hst of advertisements from a data base which relate or match the 
broadcaster's content kejwords. The web site script can also select a list of 
advertisements that relates to or match either broadcaster's content keywords or each 
hsted private viewer's profile. Depending upon the specific embodiment, one or more of 
these process steps is provided. 

Next, the web site script sends (step 351) messages to potential viewers of 
the broadcast on the immediate message Ust. In a specific embodiment, the messages can 
be sent using one of a variety of ways such as electronic mail (called e-mail), instant 
messaging, paging, faxing, and others. The web site script sends (step 353) e-mail 
messages based upon an e-mail notification Hst. The e-mail notification list is on the 
broadcaster's personal profile or the like. The e-mail messages are derived from the 
personal broadcasting server and routed to one of a pluraHty of designated e-mail 
addresses via the world wide network of computers or the like. Once the messages have 
been sent, the web site adds a session set up entry into the broadcaster's log, step 355. 
Other steps can follow. 

The above sequence of steps is merely illustrative. The steps can be 
performed using computer software or hardware or a combination of hardware and 
software. Any of the above steps can also be separated or be combined, depending upon 
the embodiment. In some cases, the steps can also be changed in order without limiting 
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the scope of the invention claimed herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and alternatives. 

Fig. 3C is a simplified flow diagram 360 illustrating a personal 
broadcasting method for activating a broadcasting session according to an embodiment of 
the present invention. This diagram is merely an example, which should not unduly limit 
the scope of the claims herein. One of ordinary skill in the art would recognize many 
other variations, modifications, and alternatives. The present method begins where the 
previous setup session ended, step 361. Here, the method can initiate the web site to go 
back via branch 363 into the set up mode, step 365, where the broadcaster could update 
previously entered profile information. Alternatively, the web site uses the default 
settings in the personal profile via branch 367. The web site verifies that the personal 
broadcasting audio/video server is running, step 369. 

Next, the broadcasting audio/video server connects to a video device 
compatible with Video for Windows™ by Microsoft Corporation, but can be others. 
Once connection has been established, the preview and/or monitor windows prompt onto 
the display coupled to the personal broadcasting audio/video server, step 373. The 
broadcaster previews and monitors information on the display. Next, the broadcaster 
gives fmal approval by providing information to a message box. The approval is 
transferred to the personal broadcasting web site. The method completes and goes to exit, 
step 377. Alternatively, the web site updates any of the stream listings to indicate that the 
broadcaster's stream is active. Such active status is provided into the broadcaster's log. 
Once the active status is provided, the personal broadcasting server decides if or not to 
send (step 381) the first requested stream to the gateway. In one embodiment, the 
personal broadcasting server waits, step 387. Alternatively, the broadcasting server 
initiates a stream of audio/video data via branch 383 to the gateway, which distributes the 
audio/video. Now the broadcasting system has been activated. Once the broadcasting 
system has been activated, the broadcaster can terminate the audio/video broadcast 
according to an embodiment of the present invention. 

The above sequence of steps is merely illustrative. The steps can be 
performed using computer software or hardware or a combination of hardware and 
software. Any of the above steps can also be separated or be combined, depending upon 
the embodiment. In some cases, the steps can also be changed in order without limiting 
the scope of the invention claimed herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and alternatives. 
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Fig. 3D is a simplified flow diagram 390 illustrating a personal 
broadcasting method according to an embodiment of the present invention. This diagram 
is merely an example, which should not imduly limit the scope of the claims herein. One 
of ordinary skill in the art would recognize many other variations, modifications, and 
alternatives. As shown, the broadcast terminates with, for example, a click of a stop 
button on the broadcaster's personal broadcasting page, step 391 . Next, the personal 
broadcasting server sends a stream terminated message to viewers of the broadcast. The 
message originates from the broadcasting server, traverses through the PBWS, and is 
transferred to one of a plurality of cHent devices, which receive and display the broadcast. 

The web site then removes (step 393) the broadcaster's stream entry from 
the stream listing. The web site script updates the broadcaster's log, step 394. In some 
embodiments, the web site also records the broadcasting sessions' stream and viewer 
statistics. In some aspects, these statistics can include, for example, length (or time) of 
broadcast, number of Megabits from personal broadcast server, average number of 
Megabits/stream from the personal broadcast server, number of streams served from the 
personal broadcast server, number of streams served from gateways on behalf of the 
broadcaster, keywords and other content or context information, characteristics (e.g., 
bandwidth, format, resolution, color depth, frame rate, contrast, brightness, source of 
stream (e.g., PBS or gateway)) of each unique or independent stream served, which is 
indexed by stream identification number, and identification of each of the viewers of the 
streams along with other information (e.g., stream identification number, start and/or stop 
times, archived stream start/stop times of each of the viewers, times at which instant 
replay is used, advertisements seen, average bit rate consumed, total bandwidth 
consumed), and other desirable information. Depending upon the embodiment, the 
method may terminate at the personal broadcasting server or the gateway. If the stream 
of audio/video has been sent (step 396) to the gateway, termination also occurs at the 
gateway in some embodiments. 

The above sequence of steps is merely illustrative. The steps can be 
performed using computer software or hardware or a combination of hardware and 
software. Any of the above steps can also be separated or be combined, depending upon 
the embodiment. In some cases, the steps can also be changed in order without limiting 
the scope of the invention claimed herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and alternatives. 
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A personal broadcasting viewing process according to an embodiment of 
the present invention is briefly described below: 

1 . Connect the viewer chent to web server; 

2. Register viewer to receive broadcast of audio/video; 

3. Input viewer client profile information; 

4. Set-up stream configuration; 

5. Select stream; 

6. View stream; 

7. Correct stream, as necessary; 

8. Terminate stream; and 

9. Perform any other steps. 

The above sequence of steps provides an easy way to register a client 
device, which will receive the audio/video broadcast. Here, the steps generally use a step 
of direct information entry of profile information to provide the web server information 
for proper formatting of audio/video streams for compatibility purposes. Although the 
above sequence generally shows direct registration, automatic or indirect methods can 
also exist. One of ordinary skill in the art would recognize many other variations, 
modifications, and alternatives. In other embodiments, some of the above steps may not 
be performed, for example, steps 4 and 7 may not be executed. Details of these steps are 
provided below in reference to the Figs. 

Fig. 4 is a sitaplified flow diagram 400 of a viewing process according to 
an embodiment of the present invention. This diagram is merely an example, which 
should not unduly limit the scope of the claims herein. One of ordinary skill in the art 
would recognize many other variations, modifications, and alternatives. As shown, the 
flow diagram 400 includes a variety of steps such as viewer registration (step 401), 
notification/check stream listings (step 403), setup stream configuration (step 405), 
activate stream (step 407), and terminate stream (step 409). The user of a client device 
such as the one noted as well as others registers the device. The client device can be 
mobile devices such as a cellular phone, a personal digital assistant, a laptop computer, a 
web appliance, a desktop computer, or any networked device capable of receiving and 
playing audio and/or video. 

Registration specifies profile information about the user and the device so 
that the web server provides selected audio/video data to the client device. In a specific 
embodiment, user registration is provided by a method 410 illustrated in the diagram of 
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Fig. 4A. This diagram is merely an example, which should not unduly limit the scope of 
the claims herein. One of ordinary skill in the art would recognize many other variations, 
modifications, and alternatives. The present method begins with a client device such as a 
viewer device. Here, the user fills (step 41 1) out a form on the web site. The client 
device can be connected to the web site or such form can be accessed through another 
cHent device including a personal computer, a workstation, and others. 

The user enters profile information on the form. The form can include 
fields for a user name, password, profile information, and other information. The profile 
information can include a list of private viewers in various groups or a designation for 
public broadcasting. In some embodiments, it may also include demographics and other 
information, which may be used by marketers, advertisers, and other agents, in 
identifying product and other information, which may be of interest to the viewer. Profile 
mformation also includes details of the client device used by the viewer as well as the 
bandwidth available to the viewer, the processing unit, memory, and operating system of 
the viewer's client device. In a specific embodiment, the form is entered from the chent, 
which sends the form to the server via the network. 

Next, the form is sent to the web site fi-om the client device where the web 
site script vaHdates the form, step 413. Alternatively, the method goes to exit (step 425) 
via branch 433 to stop the method. If the form is valid (step 415), the method continues. 
Alternatively, the method loops back via branch 427, outputs an invalid prompt (step 
423), and returns via branch 429 to step 41 1 where another form is prompted. If the form 
was valid, the method issues and records (step 417) the viewer's user name and password. 
Such user name and password are stored in memory of the web site. The viewer's profile 
is also recorded, step 419, by the web site. 

Optionally, the method allows for software to be downloaded (step 421) 
from the web site to the client device. The software allows for selected audio/video 
processing features and control aspects at the client device. In certain embodiments, the 
client device is a mobile device, which has limited processing power and memory, as well 
as constrained by bandwidth. Accordingly, it is often desirable to provide limited 
processing software to the client device since such device is often "thin" as compared to 
processing power of the web site. Once the software has been downloaded, the method 
goes to exit (step 425) via branch 431. 

The above sequence of steps is merely illustrative. The steps can be 
performed using computer software or hardware or a combination of hardware and 
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software. Any of the above steps can also be separated or be combined, depending upon 
the embodiment. In some cases, the steps can also be changed in order without limiting 
the scope of the invention claimed herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and alternatives. 

In a specific embodiment, the method has steps 440 for stream 
configuration, such as the one illustrated by Fig. 4B. This diagram is merely an example, 
which should not unduly limit the scope of the claims herein. One of ordinary skill in the 
art would recognize many other variations, modifications, and alternatives. As shown, 
the method begins where a viewer selects either an "autoview" or "configview" at stream 
Hsting entry. There may also be other selections in other embodiments. Entry is provided 
by a key, a click, voice, or other user interface device to the client. 

In the autoview configuration, the method displays the audio/video data in 
a predetermined format. Here, the method executes step 433, where the web site creates 
an HTML page (or other standard based language) based upon the viewer's profile, which 
was previously entered, and sends the HTML page to the viewer device through a 
network. Once the HTML page has been sent to the viewer device, it is ready to receive 
streaming video. 

In an alternative configuration, the viewer selects various parameters for a 
streaming video session. Here, the method allows for the web site to create (step 445) an 
HTML form on the page with fields for selected stream parameters. The HTML form is 
sent firom the web site to the viewer device through the network. The HTML form is 
prompted at the viewer device through the browsing device. Next, the viewer selects 
(step 447) the stream parameters. Here, the user can merely click on the desired 
parameters or enter the desired parameters through an interface device. The desired 
parameters through the form are sent back to the set site for configuration of the 
streaming session. 

Next, the web site forms an HTML page fi-om the parameters that were 
sent. The HTML page is transferred firom the web site to the viewer device through the 
network, step 449. The viewer device receives the HTML page, and laimches scripts of 
the HTML page automatically, step 451 . Once the scripts have been launched, the setup 
method may be completed. Next, the method can activate the stream (step 407) by 
choking on a start button. The stream can also be terminated (step 409) by chcking on a 
stop button. Alternatively, the stream can stop automatically once the streaming 
audio/video data has ceased. 
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The above sequence of steps is merely illustrative. The steps can be 
performed using computer software or hardware or a combination of hardware and 
software. Any of the above steps can also be separated or be combined, depending upon 
the embodiment. In some cases, the steps can also be changed in order without limiting 
the scope of the invention claimed herein. One of ordinary skill in the art would 
recognize many other variations, modifications, and alternatives. 

Fig. 5 illustrates an embodiment of the present invention. In particular. 
Fig. 5 illustrates look-up-tables (LUTs) used in embodiments of the present invention. 

In the present embodiment, a client device that is to receive a stream of 
video data will typically have characteristics associated with it. These characteristics are 
typically specified by a user of the client device when the user registers the chent device, 
for example in step 419, above. In an alternative embodiment, the client device may 
automatically include some indicia or characteristics of the client device such as a 
manufacturer code, product code, and the like, along with the request for the stream of 
video data. 

In the present embodiment, typical types of indicia may include the type of 
video player, the type of device it is, the bandwidth connection, the video player, the 
processor speed, and the like. In other embodiments, other types of indicia can also be 
used. 

The indicia is typically sent to the personal broadcasting site, and in 
response a series of look-up-tables (LUT§) are then accessed. The data returned from the 
LUTs are then sent to transcoder 217, and the like. In particular, the control block 2 1 5 in 
Fig. 2A may then specify the amount of subsampling or supersampling required by 
sampler block 229, the number of fi:ames per second to frame rate block 230, the color 
depth to color depth block 231, the target bit rate to bit rate control block 233, the type of 
video encoding (compression) scheme to encoder block 235; possibly an encryption key 
to encryptor block 237; the network protocol; and the like. 

Fig. 5 illustrates an embodiment of the present invention. In particular. 
Fig. 5 illustrates look-up-tables (LUTs) 500 used in one embodiment. The LUTs 500 are 
typically embodied as a data structure in a memory, and control block 215, or the hke 
access the LUTs 500 using the indicia. The output from LUTs 500 are then sent to 
transcoder 217, as described above. 

One LUT 501 is typically used to specify the network protocol used by 
stream caster 219. As illustrated, one column of the table represents a type of player, and 
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the other column represents a packetizing protocol. In one embodiment, if the client 
device is a device compatible v/ith a LuxPlayer, provided by the assignee of the present 
invention disclosxire, a real-time packeting protocol (RTP) is used. In alternative 
embodiments, other real-time protocols can also be used, for example, XJDP, RTSP, or the 
like. 

In another embodiment of the invention, if the client device is not 
compatible with the LuxPlayer, the packetizing protocol used is a transmission control 
protocol (TCP). In other embodiments, the use of other packetizing protocols is 
envisioned and other classes of players is also envisioned. 

In the present embodiment, LUT 502 is typically used to specify the color 
depth of the video stream output to the cUent device. In particular, the first column 
represents classes of client devices, and the second column represents color bit depth data 
that is passed to color depth reducer block 231 . In the present embodiment, client devices 
that are cellular telephones are provided 1 bit-depth video images; conventional PDAs are 
provided 2 bit-depth images; WindowsCE devices are provided 4 bit-depth video images; 
and personal computers are provided 24 bit-depth video images. 

In alternative embodiments, the classes of client devices can be subdivided 
and further sub-classes of devices be defined. For example, one sub-class of non- 
WindowsCE PDAs may have an assigned bit-depth of 4 bits; one sub-class of cellular 
telephones may have an assigned bit-depth greater than 1 bit; and the like. Further, other 
classes of devices may be developed and included in the future. For example, networked 
appliances may be assigned 8 bit-depth video images, or the like; further, classes of 
devices may be defined per manufacturer and/or model of devices. The LUT 502 
therefore is merely an illustration of a general concept. 

LUT 503 illustrates a LUT associated with the frame rate delivered to the 
client devices. As illustrated, the frame rate provided, in terms of frames per second, 
depends upon the quality of service (QoS) bandwidth. In other words, the number of ^s 
for video data provided to the client device depends upon the network connection to the 
client device. As illustrated in Fig. 5, the lower the bandwidth in bits per second the 
lower the number of frames per second of video image. 

LUT 503 is merely illustrative of one possible set of relationships. In 
alternative embodiments, the relationships may be modified. For example, with 14.4 
Kbps service, the number of frames per second may be .5; further, with a 56 Kbps 
service, the number of frames per second may be 8 fps; or the like. 
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The output from LUT 503 is typically input into frame rate block 230 for 
processing, as described above. Many different representations of such data are 
contemplated in embodiments of the present invention. 

In this example, LUT 504 illustrates one possible set of relationships 
between a video player, processor, the color bit-depth on a client device and a stream 
format. For example, based upon the first three colxunns, the type of stream format is 
output from LUT 504. In one example, if the chent device includes a browser and has an 
output capable of handling more than 2 bits of color information, the output stream 
format is a MotionJPEG (MJPEG). 

The stream format is then typically input to encoder block 235. In 
response, encoder block 235 encodes (compresses) the video data according to the 
requested format. In embodiments of the present invention, LUT 504 may be changed 
and different mappings between player, bit-depth, processor, and the like may be 
assigned. Further, a greater number of characteristics may be included to the LUT to add 
additional LUT entries to LUT 504. 

In the present embodiment, LUTs may exist for other parameters, than the 
one illusfrated in Fig. 5. For example, the bit rate of the video data stream may also be 
determined in response to a LUT associated with bit rates. Further, in this example, the 
resolution of the video data generated is, by default, set to the display resolution. In 
alternative embodiments a LUT may be used to lower the resolution of the video data in 
response to other parameters. 

In other embodiments, audio data may similarly be transcoded to meet the 
approprate needs of a client device. For example, the bit rate may be reduced depending 
upon the QoS described above, and the like. 

Fig. 6 illustrates an embodiment of the present invention. More 
particularly, Fig. 6 illustrates typical inputs to LUTs according to embodiments of the 
present invention and outputs from the LUTs. 

As illustrated in Fig. 6, a client device may be a personal digital assistant 
(PDA) from Palm Computing, such as the PahnVII, and the like. As is known, the Palm 
VII is powered by a 16-bit processor, runs upon PalmOS, includes a rudimentary web 
browser, has a 160x120 bit display, and has a wireless bandwidth of approximately 14 
kbps. 

In response to such data, the LUTs are then used to determine parameters 
for the video data stream to be sent to the Palm VII. For example, referring to LUT 500, 
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the player does not support the LuxPlayer, thus the packet protocol should be TCP based. 
Next, because the device type is a PDA, LUT 501 returns a bit-depth of 2 bits. Referring 
to LUT 502, the bandwidth of the connection is 14kbps, thus the frame rate is set to 1 
frame per second. Finally, in this embodiment, referring to LUT 503, the player is a 
browser, and the color depth is 2 bits, thus the encoding (compression) scheme for the 
video data is determined to be a MotionGIF format. The outputs from the LUTs are then 
used to create a video data stream tailored for the client device. 

In the present embodiment, the parameters illustrated above, such as 16- 
bits, and the like, are also stored in a LUT. In such a LUT, the data are associated with a 
device identifier that is dynamically received from the cHent device. For example, the 
chent device sends a device identifier that may specify a manufacturer or model nimiber, 
or the like. In response the identifier is used to refer to the LUT discussed above, and in 
response the LUT specifies the characteristics of the client device, hi another 
embodiment, for each client identifier, a protocol type, color depth, frame rate, and the 
like are associated in a single LUT. 

Alternatively, when the user registers her client device, she may specify 
that her client device is a PalmVII. Thus, when the user requests a video data stream, the 
chent device is already known, thus the characteristics can be easily retrieved. 
Alternatively, when the user requests a video data sfream, the exact parameters of the 
protocol type, color depth, or the like are directly retrieved. 

Example: 

To prove the principles and operation of the present invention, 
experiments can be performed to implement the present invention. Here, the present 
invention provides for an acquisition and delivery of audio and video information from a 
USB PC camera to any device, which is capable of decoding and displaying ACELP 
audio and MPEG-1 video. Management, stream initiation, sfream viewing, and other 
functions can be implemented or hosted on a web page of its own server or a web page of 
a general portal such as Yahoo!™ or others. The page can include hyperlinks for a 
variety of features such as regisfration, broadcasting, and viewing. The agents and 
database behind this web page will be termed "Directory Services." 

A broadcaster performs a one-time registration of his/her camera with the 
Directory Services via the Personal Broadcasting Cenfral web page at the general portal. 
This action will lead to the following: 
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1. A Personal Broadcasting Server (PBS) installation package will be 
downloaded to the Broadcaster's computer. PBS is the ActiveX control that will be 
launched via interaction with a general portal web page (see below) and which will 
stream MPEG-1 compressed video and ACELP compressed audio from the Broadcaster's 
machine to the Internet. 

2. The Directory Services will update its listing to reflect the 
Broadcaster's information. 

3. A log in ID and password will be issued to the Broadcaster. 

4. A Personal Broadcasting Page will be created specifically for that 
Broadcaster. It is this page that the Broadcaster will interact with whenever he/she 
wants to initiate or stop a session. 

5. A cookie will be placed on the Broadcaster 's PC. This will provide 
for immediate access to the personal broadcasting page. 

6. Other actions to be defined by general portal. 

A viewer perfonns a one-time registration with the Directory Services at 
the general portal. This action will lead to the following: 

1. A Personal Viewer (PerView) installation package will be 
downloaded to the Viewer 's computer. PerView is the plug-in which will be launched 
via the web page (see below) and which will decompress and display MPEG-1 
compressed video and ACELP compressed audio streams. 

2. The Directory Services will update its listing to reflect the Viewer 's 

information. 

3. A cookie will be placed on the Viewer 's PC. This will allow the 
Directory Services to identify the Viewer whenever he/she connects. 

4. Other actions to be defined by the general portal. 

When a Broadcaster is ready to stream, he/she navigates to the personal 
broadcasting page on which there will be "Start" and "Stop" buttons. By chcking on 
either the Start or Stop button, the Broadcaster enables or disables streaming from his/her 
machine. These buttons will be linked to PBS ActiveX control. The Start button 
activates PBS and notifies the Directory Services that the particular camera is 
broadcasting. It also notifies (via email or some instant messaging mode) a list of people 
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that the Broadcaster has specified in his/her personal broadcasting page. The Broadcaster 
also specifies that the current session is to be either private or public. If it is private then 
those registered viewers whom the Broadcaster has hsted in his/her profile will be 
notified and allowed to connect to the stream; the Directory Services will do this by 
matching viewer id's against the notification list. If the session is public, then the camera 
will be Usted by Directory Services on its pubhc page. 

Viewers choose streaiTQS either from the stream listing page. If a private 
stream is chosen. Directory Services verifies the Viewer's ID (presented by the cookie on 
his/her machine) against the list of allowed ID's. The PBWS then issues the Viewer a 
page firom which he/she can configure the desired stream (or do an Auto View). The 
configuration parameters, along with source and destination IP addresses pass as a new 
stream request to the PBWS. The PBWS then passes these to the gateway (see below) 
which, in turn, determines if these parameters are allowed and respond to the Directory 
Services. If the parameters are allowed, the Gateway decides to direct the stream either 
directly fi*om the Broadcaster to the Viewer, or have the stream go through the Gateway 
on its way to the Viewer. Later, when the Gateway HW is deployed, further processing 
by the Gateway will be possible. 

At a high level, the broadcasting system includes a variety of elements 

such as: 

1. PBS software for the streaming of audio and video from the USB 
cameras. There can be multiple streams of audio and video; each stream may have 
unique characteristics. 

2. Gateway software (version 1) for the management of streams 
between the USB cameras and client displays. The Gateway makes decisions such as: 

(a) Are requested streams possible? 

(b) Should streams be sent through the Gateway or directly 
from PBS to the Viewer. 

It is also maintains statistics on the streams. In principle, we expect that 
many instances of the Gateway software will be run; the PBWS is responsible for load 
balancing these. 

3. Client decoder software for the decompression of MPEG-1 and 
A CELP audio streams. These are separate MPEG-1 (YUV out) and A CELP (PCM out) 
decoder libraries.) 
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4. Client player software (such as PerView"^ by Luxxon Corporation) 
for the display of the decompressed streams. 

5. Personal Broadcasting Central (PB WS) web server (registration 
agents, camera hosting interface, client viewing interface) software and hardware. 

As merely an example, Fig. 7 is a simplified diagram of high level system 
architecture according to the present .experiment. This diagram is merely an illustration 
which should not unduly limit the scope of the claims herein. One of ordinary skill in the 
art would recognize many other variations, modifications, and alternatives. As shown, 
the diagram includes elements such as PBS coupled to PBWS. Also shown is a gateway 
and viewer. Here, the dotted lines represent data and the command lines are shown in the 
soHd lines. In one embodiment, the present networked structure of the PBWS-Gateway 
sub-system is expected to be on a 100Mbps or greater LAN as shown in the simplified 
diagram of Fig. 8. As shown, the interfaces include TCP or RTP for data, TCP or RTSP 
for control, ActiveX, and there may be others. 

Additional protocol information about commands and messages between 
the various elements are provided below. For easy readying, the elements have been 
provided under the underlined headings. 

Gateway: 

The protocol between the Gateway and the PBWS often reqixires that the 
PBWS issue commands to the Gateway along Avith parameters (see below) which define 
the streams and connections to broadcasters and viewers. The commands are: 



COMMANDS/MESSAGES 


DESCRIPTION 


ApproveStreamRequest 


PBWS asks the Gateway to approve a 
stream which a potential viewer has 
requested. 


NewStream 


PBWS registers and starts a new streams 
with the Gateway. 


StopStream 


PBWS requests that the Gateway 
terminates a stream which is currently 
running. 
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GetStreamStatus 


PBWS requests that Gateway returns 
statistics and other information on a 
particular stream. 


StreamError 


Gateway notifies the PBWS that an error j 
has occurred with a particular stream. 



Each Gateway generally includes a Pentium HI 500MHz by Intel 
Corporation, a 128MB or greater SDRAM, Windows NT by Microsoft Corporation, and 
two 100Mbps Ethernet NICs. 



Personal Broadcasting Server: 



Version 1 of the PBS will perform as follows: 



ll ^ ^ 1 
METRIC 


TARGET 






Output frame rates 


MPEG firame rates up to 1 5fys, but fixed for each stream 


Output resolutions 


Configurable firom VGA down j| 


Output chroma modes 


4:2:0 only 






Output Video formats 


Format 


Resolution 




MPEG-1, 2 


VGA or less 




JPEG, GIF 


VGA or less 








Major Stream Parameters 


• Resolution 

• Color Depth 

• Frame Rate 


• Bandwidth 

• Format 






Stream Controls 


• Start stream 

• End stream 






# Concurrent Streams 


Up to 8 (depends on bandwidth and CPU) 







30 



Output Color Dq)ths 


• (24bit 4:2:0 YcbCr) (1 bit BW) 1 

• (8bit gray scale) (8 bit color) 






Audio 


Format 


Bandwidth 


ACELP 


5kbps 



In other embodiments', audio can include formats such as MPl, MP2, 
MPS, G.723.1, and H.263 and MPEG-4 video. PBS defines an ActiveX control interface 
for the following actions from a form based web page: 



ACTION 


DESCRIPTION 


Start Button CUck 


Starts the PBS allowing 
either clients or the 
Gateway to initiate streams. 


Stop Button Click 


Terminates the streaming 
session. 


Video On/Off Check 


Allows Broadcaster to turn 
off video (default is on) 


Audio On/Off Check 


Allows Broadcaster to turn 
off audio (default is on) 


Preview Type List Box 


Allows user to select from 

• No preview 

• Local preview 

• Stream preview 



The following parameters define the stream to be produced and sent from 
the PBS to either the Gateway or the PerView: 



PARAMETER 


DESCRIPTION 


IPADDR 


Destination IP address 


WIDTH 


The width of the video frames 
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HEIGHT 


The height of the audio frames 


BITRATE 


The target bit-rate for the stream 


FRAMERATE 


The target frame rate for the sfream 


CONTE^AST 


The contrast gain setting [-15,15] 


BRIGHTNESS 


The 'b^rightness shift setting [-15,15] 


COLORFLAG 


The color depth 


VIDEO FORMAT 


The compression format for the video 
0 - no video 
1- MPEG-1 


AUDIO FORMAT 


The compression format for the audio 

0 - no audio 

1-ACELP 


UNUSED 


For future use 



The PBS often requires elements including PII 300MHz or greater, at least 
64MB SDRAM, Win98, at least a 56kbps modem connection with EP address, Microsoft 
compliant USB Camera, Microphone, and Microsoft compliant sound card w/ speakers. 

PerView: 

For design and testing purposes, we have developed an MPEG-1, -2 and 
ACELP and MP2 audio player called Personal Viewer (PerView). PerView as an 
embedded application in a web page is latmched. The web page is prepared and retiimed 
to the Viewer by the Gateway. It contains the following parameters that define its 
interface to both the Gateway and PBS: 



PARAMETER 


DESCRIPTION 1 


PARAMKEY 


Key to be used in decrypting param j 


DATAKEY 


Key to be used in decrypting data 


IPADDR 


IP address of the source stream/camera 
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VPORT 


The port # of the video soiirce 


APORT 


The port # of the audio source 


WIDTH 


The width of the video frames 


HEIGHT 


The height of the audio frames 


BITRATE 


The target bit-rate for the stream 


FRAMERATE 


The target frame rate for the stream 


CONTRAST 


The contrast gain settir^ [-15,15] 


BRIGHTNESS 


The brightness shift setting [-15,15] 


COLORFLAG 


The color depth (0= grayscale, 1= 24bit color) 


PLAYDURATIO 
N 


The number of seconds to continue playing 


VIDEO FORMAT 


The compression format for the video 
0 - no video 
2- MPEG-1 


AUDIO FORMAT 


The compression format for the audio 

0 - no audio 

1-ACELP 


1 UNUSED 


For future use 



The PerView includes at least a Pentium 11 300MHz or greater device by 
Intel Corporation, at least 64MB SDRAM, Win98 or higher by Microsoft Corporation, at 
least 56kbps modem coimection with IP address, and Microsoft compliant sound card w/ 
speakers. In the present example, the above parameters are encoded in the web page as a 
string of characters which must often be decrypted by the PARAM key. The key itself is 
passed as a parameter in the web page. The encryption/decryption method is often known 
to be PerView apphcation, PBWS, and PBS. 

It is understood that the examples and embodiments described herein are 
for illustrative purposes only and that various modifications or changes in light thereof 
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will be suggested to persons skilled in the art and are to be included within the spirit and 
purview of this application and scope of the appended claims. All pubUcations, patents, 
and patent applications cited herein are hereby incorporated by reference for all purposes 
in their entirety. 
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WHAT IS CLAIMED IS: 

1 1 . A system for transferring real time video information from a source 

2 device to one of a plurality of output devices, the system comprising: 

3 an image capturing device for acquiring video information, the image 

4 capturing device comprising a processor, a graphics module coupled to the processor, a 

5 browsing device coupled to the processor, a packetizing portion coupled to the processor, 

6 the packetizing portion being adapted to convert the video information into a packetized 

7 stream of information, the packetized stream of information being in a first format, and an 

8 output device coupled to the processor for transferring the packetized stream of 

9 information to a network; 

10 a network gateway coupled to the image capturing device through the 

1 1 network, the network gateway being coupled to a worldwide network of computers, the 

12 network gateway comprising a gateway transcoding device for converting the packetized 

13 stream of information from the first format to a second format, the network gateway also 

14 comprising a packetizing portion for transferring the packetized stream of information in 

15 the second format to the network; and 

16 a display device coupled to the network gateway through the world wide 

17 network of computers, the display device comprising a display device for converting the 

1 8 packetized stream of information into video information for display, the display device 

19 also comprising a display for displaying the video information on the display device. 

1 2. The system of claim 1 wherein the packetized stream of 

2 information in the first format is compressed. 

1 3. The system of claim 1 wherein the display device is coupled to a 

2 wireless network, the wireless network being coupled to the world wide network of 

3 computers. 

1 4. The system of claim 1 wherein the display device is selected from 

2 one of a plurality of devices including a portable computer, a laptop computer, a personal 

3 digital assistant, a web appliance, a personal computer, and a work station. 

1 5 . The system of claim 1 wherein the first format is different in type 

2 from the second format. 

1 6. The system of claim 1 wherein the first format is selected from the 

2 group consisting of MPEG-1, MPEG-2, MPEG-4, H.263, M-JPEG, M-GIF, ACELP, 

3 MPl, MP2, MP3, and G.723.1. 
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1 7. The system of claim 1 wherein the second format is selected from 

2 the group consisting of MPEG-1, MPEG-2, MPEG-4, H.263, M-JPEG, M-GIF, ACELP, 

3 MP1,MP2,MP3, andG.723.1. 

1 8. The system of claim 1 wherein the image capturing device is a 

2 video camera. 

1 9. The system of claim 1 wherein the network gateway comprises a 

2 look up table. 

1 10. The system of claim 1 wherein the image capturing device is 

2 coupled to a personal computer that is coupled via a wireless medium to the network. 

1 1 1 . A system for personal broadcasting to a mobile display device 

2 comprises: 

3 a processor; and 

4 a personal broadcasting server coupled to the processor and coupled to a 

5 wide area network of computers comprising: 

6 an image retrieval portion configured to retrieve incoming video 

7 signals in a first format; 

8 a look up table coupled to the personal broadcasting web site for 

9 determining parameters for a second format for the incoming video signals; and 

10 a transcoding module coupled to the image retrieval portion and to 

11 the look up table, the transcoding module configured to convert the incoming video signal 

12 from the first format into the second format in response to the parameters; 

13 wherein the second format is more appropriate for the mobile display 

14 device than the first format. 

1 12. The system of claim 1 1 wherein the image retrieval portion is 

2 configured to receive the incoming video signals from a video camera. 

1 13. The system of claim 1 1 wherein the image retrieval portion is 

2 configured to receive the incoming video signals from a data file. 

1 14. The system of claim 1 1 wherein the second format is compressed. 

1 15. The system of claim 1 1 wherein the first format is selected from 

2 the group consisting of MPEG-1, MPEG-2, MPEG-4, H.263, M-JPEG, M-GIF, ACELP, 

3 MP1,MP2,MP3, andG.723.1. 

1 16. The system of claim 1 1 wherein the second format is selected is 

2 selected from the group consisting of MPEG-1, MPEG-2, MPEG-4, H.263, M-JPEG, M- 

3 GIF, ACELP, MPl, MP2, MP3, and G. 723.1. 
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1 17. The system of claim 1 wherein the parameters from the look up 

2 table includes pixel bit-depth data. 

1 18. The system of claim 1 wherein the parameters from the look up 

2 table includes frame rate data. 

1 1 9. A distributed system for broadcasting personal sfreaming data 

2 comprises: 

3 a video data source cqupled to a network, the video data source configured 

4 to provide an output stream of video data, the output stream of video data having a first 

5 set of video parameters; 

6 a client device coupled to the network, the client device configured to 

7 receive an input stream of video data, the input sfream of video data having a second set 

8 of video parameters, and configured to output a device identifier; 

9 a gateway server coupled to the video data source and to the client device 

10 across the network, the gateway server configured to receive the output stream of video 

1 1 data and to receive the device identifier, and in response to generate the input stream of 

12 video data in response to the device identifier; and 

1 3 wherein at least one parameter in the first set of video parameters is larger 

14 than a corresponding parameters of the second set of video parameters. 

1 20. The system of claim 19: 

2 wherein the video data source is also configured to receive video data, and 

3 wherein the output stream of video data is determined in response to the 

4 video data. 

1 21. The system of claim 1 9 : 

2 wherein the video data source is also configured to retrieve a data file from 

3 a memory, and 

4 wherein the output sfream of video data is determined in response to the 

5 data file from the memory. 

1 22. The system of claim 19: 

2 wherein the gateway server comprises a look up table, the look up table 

3 associating the device identifier with the second set of video parameters; and 

4 wherein the gateway server generates the input sfream of video data in 

5 response to the second set of video parameters. 

1 23 . The system of claim 1 9 wherein the at least one parameter in the 

2 first set of video parameters is a frame rate parameter. 
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1 24. The system of claim 1 9 wherein the at least one parameter in the 

2 first set of video parameters is a bit rate parameter. 

1 25 . The system of claim 1 9 wherein at least another parameter in the 

2 second set of video parameters comprises a compression format. 

1 26. The system ofclahn 25 wherein the compression format is selected 

2 from the group comprising: GIF, JPEG, MPEG. 
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PERSONAL BROADCASTING SYSTEM FOR AUDIO AND VIDEO DATA USING 
A WIDE AREA NETWORK 



ABSTRACT OF THE DISCLOSURE 

5 

A system for transferring real time video information from a source device to 
one of a plurality of output devices includes an image capturing device for acquiring video 
information, the image capturing device comprising a processor, a graphics module coupled 
to the processor, a browsing device coupled to the processor, a packetizing portion coupled to 

10 the processor, the packetizing portion being adapted to convert the video information into a 
packetized stream of information, the packetized stream of information being in a first 
format, and an. output device coupled to the processor for transferring the packetized stream 
of information to a network, a network gateway coupled to the image capturing device 
through the network, the network gateway being coupled to a worldwide network of 

15 computers, the network gateway comprising a gateway transcoding device for converting the 
packetized stream of information from the first format to a second format, the network 
gateway also comprising a packetizing portion for transferring the packetized stream of 
information in the second format to the network, and a display device coupled to the network 
gateway through the world wide network of computers, the display device comprising a 

20 display device for converting the packetized stream of information into video information for 
display, the display device also comprising a display for displaying the video information on 
the display device. 

PA 3049658 v2 




■H6. ZA 



OCT 
Subaamplar" 



L4C> 



Color Dapth ^ 




O 
AX 



U Q 





60 
C 




±3 e3 

w O 




L 










Videc 
Comi 










s 


o 


> a: 






ame 


iffer 





o 



.1 



> >s 



II 
id 



> Q Q 



«^ O Q 



i 



u 

a 
o 

Oh 

o 



c3 





o 






"> o 


i 


L 




•1 


8 


8 




i 






1 







en 



2 



<0 u. 



o ^ "C 
w O Q 



o 
o 

Ph 

a 

• tH 

o 

O 

o 

Ph 



(No 



t 



•^3 



1 



O 



« 

.6 



U- 



o 



\x 



CD 

O 
O 

PQ 



CO 



> 



CO q 



1 1^ 

^ ° I 

PLH C/3 .S 




57 



Client Mobile Device Capability: 



DeviceType 


Processor 


OS 


Player 


Display 


Bandwidth 


PDA 


16bit 


PalmOS 


Browser 
(no javascript) 
(no audio) 


160x120 


14kbps 



Map to internal structure: 



StreaniFormat 


Resolution 


ColorDepth 


FrameRate 


ProtocolType 


MotionGIF 


160x120 


2bit 


l^s 


TCP 



Mapping: 

Resolution = Display I 



Player 


ProtocolType 


LuxPlayer 


RTP 


Others 


TCP 




DeviceType 


ColorDepth 


CellPhone 


Ibit 


PDA 


2bit 


WinCE 


4bit 


PC 


24bits 








QoS Bandwidth 


FrameRate 




14.4kbps 


Ifps 




28.8kbps 


2fps 




33.6kbps 


4fps 




128kbps 


8£bs 




324kbps 


15fps 




> 324kbps 


30fps 





J 

^02 



^05 
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Player 


ColorDepth 


Processor 


StreamFormat 


Browser 


Ibit, 2bits 


ANY 


MotionGIF 


Browser 


>2bits 


ANY 


MotionJPEG 


ANY 


Ibit, 2bits 


<266MHz 


MotionGIF 


ANY 


> 2bits 


<266MHz 


MotionJPEG 


Otherwise 






MPEG/MP3 audio 



PBS 



*' Mediator 



Viewer 



flQ-7 



Router 



lOOMbps 
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DECLARATION AND 1»0WER OF ATTORNEY 

As & below named inventor, I declare that: 

My residence, post office address and citizenship are as stated below next to my name; 1 believe I am the original, first and sole 
inventor (if only one name is listed below) or an original, first and joint inventor (if plural inventors are named below) of the subject 
mauer which is claimed an<i for which a patent is sought on the invention entitled: PERSONAL BROADCASTING SYSTEM FOR 

AITDTO AND VIDEO DATA USING A WIDE AREA NETWORK the specification of which is attached hereto or was 

filed on as Application No. ^ and was amended on (if applicable). 



I have reviewed and understand the contents of the above identified specification, including the claims, as amended by any 
amendment referred to above. I acknowledge the duty to disclose infomiation which is material to pateniability as defined in Title 37, 
Code of Federal Regulations, Section 1.56. 1 claim foreign priority benefits under Title 33, United States Code, Section 119 of any 
foreign applieation(5) for patent or inventor's certificate listed below and have also identified belov/ any foreign application for patent 
or inventor's certificate having a filing date before that of the application on which priority is claimed. 

Prior Foreig n Application(s) 



Country 


Application No. 


Date of Filing 


Priority Claimed Under 
35 use 119 











1 h'#by claim the benefit under Title 35. United States Code § 1 19(e) of any United Slates provisional application(s) listed below: 













Application No. 


Filing Date 






60/170,079 


December 9, 1999 | 



I cteim the benefit under Title 35, United States Code, Section 120 of any United States application(s) listed below and, insofar as the 
su||6ct matter of each of the claims of this application is not disclosed in the prior United States application in the manner provided by 
th^^rst paragraph of Title 35, United Slateji Code, Section 112, 1 acknowledge the duty to disclose material information as delined in 
Titti37, Code of Federal Regulations, Section 1.56 which occurred between the filing date of the prior application and the national or 
PGJ international filing date of this application: 



Application No. 


Date of Filing 


Status 









POWER OF ATTORNEY: As a named inventor, T hereby appoint the following anomey(s) and/or agent(s) to prosecute this 
application and transact all business in the Patent and Trademaric Office connected therewith. 



Stephen Y. Pang, Reg. No. 38,575 
Richard T. Ogawa, Reg. No, 37,692 



Send Correspondence to: 


Direct Telephone Calls to: 


Richard T. OgHwa 


(NAme, Reg. No., Telephone No.) 


TOWNSEND and TOWNSEND and CREW LLP 


Name: Richard T. Ogawa 


Two Embarcadero Center, 8* Floor 


Reg. No.: 37,692 


San Franclksco, California 94111-3834 


Telephone: 650-326-2400 
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Full Name of 
Iiiv«ntOr I; 


LqsI Kume: 

BROOKS 


First Name: 
ROGER 


Middle Nome or Initid: 

K 


Residence & 
Citizenship: 


City: 

Palo Alto 


Siatc/Forcign Country: 

California 


Country of Citizenship; 

United States 


Post Office 
Address: 


Post Oflice Address: 
690 WUdwood Lane 


City; 

Palo Alto 


State/CountFy: 
California 


Postal Code; 
94303 


Full Name of 
Inventor 2: 


Lagi Name; 
Ma 


FiistName: 

Yanda 


Middle Name or Icu 


(ial: 


Residence & 
Citizenship: 


City: 

Mllpitas 


State/Fonrfgn Coutiny: 

California 


Counliy urCitizensliip: 

Canada 


Post Office 
Address: 


Pobtt Office AddreM: 
1702 Tahoe Drive 


City: 

MUpitas 


Stttte/Couatiy: 
California 


FosUI Code: 
95035 


Full Name of 

Inventor 3: 


Last Name; 
Singhal 


First Name: 

Dave 


Middle NsuiB or In 
M. 


tial: 


Rcni Jence & 
Citizenship: 


CKy: 

Saa Jose 


Statc/Forcijiii Cuuntiy: 
California 


Cuunlry uf Ciiizciuhip: 

United States 


Post Office 
Address: 


Fost Office Address: 

441 London Park Court 


City: 

San Jose 


Slale/Country: 
California 


Puiilal Code: 
95136 


Full Name of 
Inventor 4: 


Lasi Name: 
Hong 


First Name: 

Xia 


Middle Name or Im 


tial: 


Residence A 
Citizenship: 


City: 

San Jose 


State/Foreign Countiy: 

California 


Country of CitiTenship; 
United States 


Post Office 
Address: 


Poat Office Addross: 

1074 Heatherfield Lane 


City: 

San Jose 


State/Country: 

California 


Postal Code: 

95132 


Full Nunc of 
Inventors: 


Last Name: 


Kirsl Name: 


Middle Nattie or Ini 


ial; 


Residence 
Citizenship; 


City; 


Siate^oreign Country: 


Country of Citizenship; 


Post Office 
Address: 


Post Office Address: 


City 


State/Country: 


Postal Code: 













aref^lieved to be true; and furtiier that these statements were made with the knowledge that willfUl false statements and the like so 
™# are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such willful 



SijJ^Uircorttivcntor 1 


Signature of Inventor 2 


Signature of Inventor 3 




YATvIISma 


DAVE M. STNGHAL 


Date l^^^jm:: 


Date IhkiM 


Date i'^^/^pfe^... 


Signature of inventor 4 

aa^> 


Signature of Inventor 5 


Signature of Inventor 6 


XIA HONG 






pate %ll^^fo^ 


Date 


Date 
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